The present invention relates to a simulator for simulating an intelligent network, in particular for locating and analyzing weak points, testing network configurations and/or control mechanisms, and determining ways to increase the network""s performance.
All over the world, the term intelligent network (IN) is used to describe a network architecture that applies to all telecommunication networks. At the heart of this concept is an individual, software-defined communication profile for customers of telecommunication services. The IN combines important functions and data in a central location and provides them in only one or just a few nodes. These functions and data include, for example, information on how a call with an IN-specific telephone number is to be handled depending on its place of origin, the phone number dialed, the time or day, and/or other parameters, e.g., whether and to which network subscribers a call is to be forwarded, whether and to which recorded announcements a call is to be switched, or whether a call is merely counted. The intelligent network provides an intelligent, distributed database access capability from a plurality of service switching points (SSPs) to data and functions stored in one or just a few service control points (SCPs) for the purpose of controlling the service.
From an organizational standpoint, the intelligent network is a centralized network above a telephone network and provides the intelligence for setting up and releasing calls conducted over the telephone network. The interface between the telephone network and the intelligent network is formed by the SSPs, where calls with IN-specific telephone numbers arrive and, after receiving the processing information from the SCP, are processed according to these instructions, e.g., they are forwarded to a telephone number provided by the SCP.
The individual function complexes are implemented on separate system levels within the intelligent network. IN transport and switching functions are implemented on the service switching point (SSP) level, service control and service data management functions on the service control point (SCP) level, and service management functions in the service management system (SMS). The SSP and SCP levels communicate via the signaling system No. 7 (SS7) over which IN-specific messages are sent for call handling purposes. Signaling transfer and control within the SS7 system are handled by one or more service transfer or service relay points (STP and SRP). The STP or SRP is used to switch and distribute (route) messages on the central signaling channel between the SCP and SSP. The STP or SRP can also serve as a gateway for messages that affect the IN services of a different carrier and must be processed by the SCP in a different IN. An important routing criterion of an IN message is its global title; the STP/SRP level carries out the global title translation (GTT) function.
The SSP level has mechanisms for detecting IN calls, e.g., based on the telephone number, and for supporting these calls. In the case of these calls, an SCP has to be interrogated to obtain information needed to continue setting up the call. The SCP contains programs and corresponding data for controlling the services. In addition, the SCP collects data for billing purposes and statistical analyses. Multiple SSPs access one central SCP. The SCP is subordinate to the service management system, which administers the IN services and IN components.
An intelligent network can be used to implement the following IN services, among other things:
Televoting (televotum) (TV): the televoting service enables the service subscriber to record the number of calls placed to is televoting number. According to one version of this service, the SCP is interrogated each time a call is made, while in another version the calls are pre-counted in the SSP, with the SCP being interrogated only after k number of calls have been processed. Regardless of the version selected, each TV call arriving in the IN system is recorded. In addition, each nth call can be handled in a special way depending on the active traffic routing program, e.g., forwarded to a destination address defined by the service subscriber after being recorded. All other calls are transferred, after being recorded, to a recorded announcement which was also defined in the service subscriber""s traffic routing program.
Freephone (FPH): the freephone service allows service users to place a toll-free call to the xe2x80x9cservice subscriberxe2x80x9d. The service subscriber pays all charges.
Universal number (UNU): the universal telephone number service enables callers to reach a service subscriber under a standard, local network-independent telephone number regardless of his present location. The charges for calls of this type may be assigned to the caller only or shared between the calling and called parties, depending on the option selected by the service subscriber.
Tele-info service (TIS): the tele-info service gives callers access to a range of information provided by the service subscriber by dialing the latter""s recorded announcement equipment or through direct dialog. The charges are billed to the caller and can be shared between the carrier and service subscriber on the basis of the call-specific information.
Other services are also possible, such as assigning a telephone number to a customer instead of to a line and redirecting all calls made under this telephone number to the customer""s present location. In this sense, mobile radio networks are also intelligent networks.
The service subscriber has the option of specifying his service based on additional service features, including: Rerouting: if the dialed subscriber does not answer or the line is busy, the call is either switched to a recorded announcement or another number. This procedure can be repeated up to a preset number of attempts, after which the call is rejected.
Call limit: if the number of calls to a destination number exceeds the limit defined by the service subscriber within a certain period of time, the excess calls are routed to defined alternative destination numbers or recorded announcements.
Time-dependent destination control: the time of the call is compared to the periodic and/or temporary time window. If no valid time window is found, the SCP transfers the IN call to a standard advisory message; otherwise it branches to the call destination or to the next feature.
Origin-dependent destination control: the network origin information is compared to the origin information stored in the traffic routing program. If no match is found, the SCP transfers the call to a standard advisory message; otherwise it branches to the call destination or to the next feature.
Call distribution: the call distribution feature enables users to define individual quotas according to which calls are distributed to different destinations.
If a call is switched to a recorded announcement, the SSP acts like a fictitious communication party. The SSP supports network service-specific standard advisory messages and recorded announcements that can be controlled as call destinations. The individual recorded announcements have a limited number of attendant consoles. If all attendant consoles are busy, the excess calls are rejected. Each message is limited by a maximum playback time and number of repetitions.
For most of the IN services, e.g., FPH, UNU, TIS, and TV without the pre-counting function, the function of the intelligent network is to translate the dialed IN number to a real number as a function of defined service parameters in the traffic routing program. This is done according to the following main sequence:
1. The SSP evaluates the first few digits in the dialed telephone number and detects the IN service. The SSP sends a PROVIDE INSTRUCTION message to the SCP asking how this call is to be handled. The message contains the IN subscriber number dialed by the service user (CALLED PARTY ADDRESS) and the caller""s telephone number (CALLING PARTY ADDRESS) as parameters.
2. In the SCP, the PROVIDE INSTRUCTION message accesses the service logic program for the corresponding IN service. The subscriber-specific traffic routing program addressed by the CALLED PARTY ADDRESS is activated. In the procedure described here, the result of this is to determine a destination for setting up the call, which can be either a telephone number or a recorded announcement. In addition, the traffic routing program can provide requests for monitoring the call, such as monitoring of xe2x80x9csubscriber busyxe2x80x9d and xe2x80x9csubscriber does not answerxe2x80x9d. The SCP saves the results in a call-specific context and sends the CREATE-JOIN and MONITOR messages to the SSP. The message contains the CALLED PARTY ADDRESS and EVENT LIST, which specifies the events to be monitored, as parameters.
3. The SSP sets up a call to the B party over the telephone network using the destination number transferred in the CREATE-JOIN parameter or switches the call to a recorded announcement.
4. The SSP monitors the call setup procedure to the B party, if this was specified in the EVENT LIST. If the B party does not respond, the call placed to the B party is released at the and of a timeout, and the SCP is notified of the event via the EVENT message.
5. The traffic routing program defines an alternative (rerouting) destination and sends a CREATE-JOIN and MONITOR message containing the appropriate parameters to the SSP.
6. The SSP sets up a call to the B party over the telephone network using the destination number transferred in the CREATE-JOIN parameter or switches the call to a recorded announcement. When the B party answers, the call is put through.
7. At the end of the call, the SSP collects the call charge and statistic data needed in the SCP and transfers it in the EVENT(CALL END) message. In the SSP, a timer monitors confirmation of this message by the SCP. If no confirmation arrives before the timer expires, the EVENT(CALL END) message is sent again.
8. After receiving the EVENT(CALL END) message, the SCP sends a message to end the TCAP dialog. The SCP reactivates the call-specific context. The received time stamps are saved along with the data stored in the context (call tickets). They are transferred to the SMS later on for further processing. Counters maintained in the SCP (e.g., for successful call attempts) are incremented (counter tickets).
Points 4, 5, and 6 of this sequence occur only when a call is rerouted.
To ensure that the IN continues to operate properly even with a high traffic volume, overload protection mechanisms are provided in the IN. The overload protection mechanism causes the SSP to reject IN calls without first interrogating the SCP according to certain criteria. Examples of overload protection mechanisms include AUTOMATIC CALL GAPPING (ACG) and the LEAKY BUCKET method. Overload protection can be based on services and/or destinations.
A service control point is usually a multi-layer system with a hardware base and multiple software layers (usually three). The hardware base includes a computer with one or more parallel processors as well as trunks, hard disks, magnetic tapes, terminals, and printers. The first software layer contains the system software. The second software layer (NODE software) contains general functions for the service application. The third software layer provides the application that supports the call-processing services. If the SCP has a parallel-processing architecture, it includes a plurality of processors, each of which forms a self-contained unit with a CPU, main memory, power supply unit, and input/output processor and is connected to the others by a bus system.
The various SCP software layers include operating system processes and general processes that do not belong directly to the operating system, such as those for communication between the processes or for efficient local cache management, as well as application processes which are needed for processing an IN message. An IN message arriving at the SCP thus passes through a sequence of processes in various SCP layers, resulting in the generation of an IN message sent by the SCP to the SSP in response to the SSP""s request for call handling instructions. The processes can be service- and/or service subscriber-dependent or they can be used independently of the service or subscriber in all IN messages. The processes are implemented in one or more incarnations on all or only selected processors in an SCP.
An IN message is generally processed by the SCP according to the following scheme, implemented by calling up a preset chain of individual processes:
A message from the SSP is received and forwarded to the SCP computer. The SCP computer receives the messages, provides storage space, and checks the message to determine its validity range. The call handling context is drawn up. A routing tree is loaded from the working memory or from the hard disk. The telephone number to be dialed is selected from the routing tree. The context to place the call is stored and a reply to the SSP is prepared. The reply is sent to the SSP in the form of a new IN message.
All processes needed to process an IN call are activated on only one processor, and the preceding process must be terminated before the next process can begin.
The end-of-call handling after the caller has released the call from the exchange to the SPP is processed in the same manner as the call setup handling described above using a corresponding process chain.
An IN message in the STP/SRP is also processed by processing a predetermined chain of consecutive processes.
Long average processing times have been observed during measurements conducted in existing IN networks, in particular on their central component (the SCP). This leads to unacceptably long call setup times when the system is heavily loaded by IN traffic, in particular during peak hours involving the televoting service, but also as a result of other influences. However, it is difficult to analyze weak points in the IN network which could lead to such long response times, since the measured values are merely statistical data and a measurement cannot be conducted during each stage of message processing. In addition, conducting measurements in real INs poses a fundamental problem in that all real detailed measurements influence the performance of the system to be investigated by activating additional measurement processes that are not part of the regular IN call handling functions.
A further problem arises when implementing new components in an existing IN. The IN is in operation at each point in time, making it impossible to change parameters in this complex system without jeopardizing operating reliability. It is also not presently possible to determine whether, for example, processors having a certain technical specification actually achieve the performance levels promised by the manufacturer.
In addition to the need to analyze weak points in existing intelligent networks, there is also a need to test as yet unimplemented network configurations as early as the planning stage so as to determine the configuration that has the best performance under given basic conditions. For example, the question arises as to how powerful the SCP or its individual processors must be or what capacities must be provided, and possibly in what form, for the individual services. The question also arises as to whether and how better performance can be achieved, possibly by changing the process management functions within the IN processors. A further critical element in operating an intelligent network is the overload protection mechanism which is supposed to stabilize the system as closely as possible to its performance limit. In practice, corresponding overload protection parameters can be determined only with great difficulty, which means there is a need to determine the optimum overload protection settings as a function of other network configurations and independently of network operation and to transfer them to the real network.
An object of the present invention is therefore to provide a tool for measuring the performance of a communication network with an IN structure. In doing this, the user should be able to set and change a wide range of network configurations and call handling methods within the network components, i.e., the simulation must be independent of the selected IN platform. Statistical data on network performance must be generated which can be compared to data measured by real IN components; however, data which cannot be accessed in real networks should also be provided, for example call-specific logging of the processing times as the call passes through the intelligent network.
This object is achieved according to the present invention with a simulator for simulating the performance of an intelligent network (IN) having the following components:
1. a module for simulating any IN-typical event sequences (traffic simulator) according to the rules of traffic theory;
2. a module for the event-oriented simulation of the service control point (SCP simulator) using process models;
3. means for exchanging data between the modules;
4. means for entering and storing the network configuration, communication service specification, and other simulation parameters, and for transferring them to the correct modules;
5. means for outputting and/or storing the simulated data.
Because the reasons for the performance shortcomings in the intelligent network can frequently be found in the central SCP, due to the network""s centralized structure, the SCP model forms the heart of the simulator. Queue modules and process models make it possible to create a detailed model of the SCP software structure. A further module, the traffic simulator, is needed in the IN simulator to generate an IN-specific load and to produce realistic input for the SCP simulator.
The simulator is implemented at the core by a computer program. At startup, or during simulation, this program accesses files in which are stored parameters for configuring the network or the network components, for specifying the communication services, i.e., the type and sequence of call handling functions, and other parameters that affect the simulation run, such as information about the traffic volume. The user can write and change these files in the usual manner. The simulation parameters are preferably entered using a computer monitor and keyboard. The simulation parameters are stored and can be modified individually or in their entirety prior to running a new simulation, making it possible to selectively analyze the influence of individual parameters on the simulated IN performance.
The simulation method used is an event-controlled simulation. IN-specific events, which pass through the individual simulator components for processing, are generated at specific points in time. The processing times that arise in the individual simulation modules, and possibly also in subcomponents of the simulation modules, are also logged. In addition to the basic components of SCP simulator and traffic simulator, the IN simulator preferably also has a module for the event-oriented simulation of the signaling system No. 7. This SS7 simulator operates on the basis of queue models to the extent that functionalities in the SS7-integrated processors are to be simulated, and/or provides a message with only one constant delay time that takes into account the finite runtime on the signaling channels between the SSP and the SCP. The components to be simulated by the SS7 simulator are the processors/process chains on the SSP level, the STP/SRP level, and, depending on the network configuration, the SCP level, e.g., an SCP input processor (FRONT-END SYSTEM) which forms the interface between the SCP and the signaling system.
In a further advantageous embodiment of the present invention, a module for simulating overload protection mechanisms is provided. This overload protection simulator modifies the number of events processed by at least one of the other simulation modules as a function of the load on one or more simulation modules, e.g., as a function of the queue length, and/or as a function of user-definable parameters. The user-definable parameters can include, for example, load tolerance limits which, when exceeded, activate the overload protection mechanism. Instead of permanently defined limits, a xe2x80x9cfuzzyxe2x80x9d determination can also be provided, e.g., using fuzzy logic. An overload protection simulator that receives its control parameters from the SCP simulator, accesses the traffic simulator, and regulates the number of IN events generated or forwarded by the traffic simulator as a function of the control parameters comes closest to simulating real events. After manipulating the overload protection mechanism, there is a certain probability that a call which was first generated by the traffic simulator will not be transformed into an IN event corresponding to a request from the SSP to the SCP, and is therefore not passed on to the other simulation modules. In reality, this is a call that is rejected by the SSP.
The overload protection simulator advantageously simulates the Automatic Call Gapping (ACG) mechanism. In this case, all calls or events exceeding a certain number are rejected within a certain interval.
The traffic simulator, SCP simulator, and possibly the SS7 simulator and overload protection simulator modules are separate simulators of the corresponding network components. Internally, their functions are either linked by files (file mode) or preferably integrated by an organization program (online mode) which processes the individual IN events across all components of the IN simulator.
In file mode, the simulation modules communicate with each other by performing read and write access to files in which the data relating to the network configuration or network components to be simulated, and possibly the data generated by one of the simulation modules, is stored.
To carry out a full network simulation, the partial simulations are invoked consecutively. A simulation run begins when the traffic simulator generates the traffic volume in the IN. The generated messages (PROVIDE INSTRUCTION, with its generation time t1, EVENT or CALL END) are stored in a first transfer file and read in by the simulation module, which is subsequently invoked. A call identification number, which enables multiple messages to be assigned to the same call and thus, in the end, to determine call-specific response times, is also stored for each message. In the simplest simulator version, this second simulation module is the SCP simulator. Taking the SS7 into account, the first file is then transferred to the SS7 simulator. In this case, SS7 output time t2 is added to the messages after the latter pass through the SS7 simulator, and the messages are written to a second transfer file that is accessed by the SCP simulator. The SCP simulator generates a CREATE-JOIN or CALL END message for each of the entries present in the file transferred to the simulator and writes the message, together with output time t3, to a third file. Before the message arrives at the SSP, the SS7 simulator is run once again, logging SS7 output time t4.
By determining the difference between the logged time stamps, the delay times in the individual network components and in the overall network can be derived from the transfer files of the simulation modules.
Because the sequential operation of the partial simulations prevents any sort of feedback loop between the network components, the procedure described above is carried out multiple times to reach a steady state and largely simulate the functionalities of the real network.
File mode is highly suitable for studying the behavior of individual network components separately from the network, i.e., without feedback. The behavior of the individual components can be determined quickly and directly, for example by modifying the corresponding simulation parameters. The individual IN components can be modified and analyzed separately. File mode also enables all individual EVENTS between the components to be easily tracked. Due to the stationary behavior of the overall system, however, file mode allows only iterative determinations to be made, based on suitable initial conditions.
In online mode, an organization program ensures that the partial simulations run more or less in parallel. The simulator is thus able to simulate the network as a whole and, in particular, to take into account feedback between the components directly. Event calendars are used to convert the message processing operations in the network components, which run parallel in a real network, to sequential or quasi-parallel processing operations of the IN events in the simulation modules. An event calendar is a list of all events that are to be processed by one element, e.g., the simulator, a simulation module, or a sub-component of a module, e.g., IN messages or individual processes that are entered in this list in chronological order. The event calendar enables the online simulator to specify which event will be processed next (event-oriented simulation). The time at which the next event starts is derived additively from the starting time and duration of the preceding event. The global event calendar, which contains the events to be processed by all the simulation modules as a whole in chronological order, plays a central role in operating the simulation modules in quasi-parallel mode. On the basis of the global event calendar, the simulator specifies which partial simulation is to be invoked at which simulation time. In addition to the global event calendar, there are also local event calendars that are managed by the simulation modules. Events in the following event groups are entered in the global event calendar:
Internal events: internal events are references to the local calendars in the corresponding simulation modules. They affect how a simulation module progresses to the next simulation step.
External events: external events are the input of an IN message in a partial simulation; they represent messages that are exchanged between the simulation components and are used for communication between the simulation components.
Call-independent events: according to one embodiment of the present invention, events that are independent of the IN events and belong, for example, to the simulation of the operating systems in the sub-components, are also entered in the global calendar.
All events generally cause the respective simulation modules to generate a follow-up event which, in turn, is entered in the global event calendar and, in some circumstances, in the local event calendars as well. Some events, after being processed, trigger a logging operation on the basis of which the speed at which a message was processed by the corresponding simulation module can be determined.
The user can preferably access the functions of the IN simulator via a user interface. This interface administers one or more simulations by providing input screens for entering the simulation parameters of the individual simulation modules, stores the entered data in corresponding files, and saves it according to simulation. The user can generate a new simulation by copying and modifying selected parameters. The user interface includes a largely independent file management system for the system of configuration and event files belonging to each simulation. The user can display all simulated data. The xe2x80x9cmeasured quantitiesxe2x80x9d selected by the user, e.g., SCP utilization, queue length in the SCP, traffic volume in the IN, are prepared with the help of a graphic program and can be displayed in graphic form on a computer screen. The simulation results of one simulation as well as different simulations can advantageously be displayed together on the same screen. In addition, file filters can advantageously be used to generate output files for further processing the data in other programs.